Many Internet users have specific access rights to their service provider, to a corporate network, to paid services, or to their bank or credit account. For exercising their rights, such users need to authenticate themselves. The most known and commonly-used method for user authentication is based on entering a username and a password.
With the growing rate and sophistication of Internet fraud, username and password authentication is not considered safe, since the data can be easily intercepted through the communication network, and then be reused by the attacker for false representation of the original user's identity and rights.
One-time-password (hereinafter “OTP”) is a common remedy, offered by various vendors, to overcome the vulnerability of the username and password scheme. It is based on using a password only for a single login or transaction, and then rendering this password useless. Any further login or transaction will require a different password. Thus, even if someone intercepts the password, it is useless for future transactions.
There are three basic methods for generating and managing a one-time password. One is to have a long list of passwords on a paper or electronic file; the second is to use software running on one's personal computer (desktop, laptop, palmtop or smart phone) to generate such passwords; the third is to use a dedicated hardware device to generate the passwords. The focus of the present invention is on such hardware devices.
FIG. 1A describes system 100 of the background art, which uses a dedicated OTP authentication device 110 (typically, a OTP “token”) for generating a one-time password. Computer 160 includes processing capacity (not shown) for running client application 168 in cooperation with server application 182 running on a server 170, to obtain a target functionality, such as access to information or transactions. Client application 168 can be a dedicated program or a general purpose Web browser. Server application 182 requires approval from OTP verifier 178 in order to provide the target functionality. OTP verifier 178 is a software module devised to receive and check a (one-time) password from server application 182, which in turn has received that password from client application 168. In the configuration under consideration, that password is derived from data generated by and received from OTP authentication device 110 through authentication device interface 164. OTP authentication device 110 is a secure portable device that is carried by a user and is adapted to interface with a plurality of computer 160. The heart of OTP authentication device 110 is OTP generator 130, which is a microprocessor-based cryptographic software routine, devised to generate a one-time password based on trigger 120 and a secret user key 132 recorded in OTP authentication device 110. Typically, the OTP device 110 is constructed to be tamper-resistant or tamper-proof to prevent access to and/or tampering with the secret user key 132 data.
Trigger 120 is the element that changes from one password generation operation by OTP generator 130 to other generation sessions, and hence provides the “one-time” aspect of the password. Three common approaches in the background art for generating trigger 120 are a random challenge 120A received from server 170, a full date time string received from an accurate real-time clock 120B built into OTP authentication device 110, or a counter 120C that increments by 1 for each consecutive password generation.
Throughout this disclosure, “session OTP data” refers to data derived from trigger 120 and secret user key 132. This Session OTP data may be combined, within the OTP authentication device 110 and/or the client workstation 160 with user authentication data (i.e. password, biometric data, etc) to yield two-factor (or multi-factor) authentication data. For the specific case where the combining is effected within the OTP authentication device 110, the two-factor authentication data is itself a form of “Session OTP data.” Nevertheless, there is no explicit requirement that the “Session OTP data” as provided from the OTP device 110 to the client workstation 160 be multi-factor authentication data derived from a user-provided data (i.e. password/PIN data or biometric data), as long as the Session OTP data is derived form the user key 132 and trigger 120.
Optionally and typically, user identifier (or user identification module) 134 may be provided in OTP authentication device 110 to prevent misuse by someone who finds or steals OTP authentication device 110. In many implementations, OTP generator 130 will not generate (or will not transmit) a Session OTP data unless user identifier 134 provides positive user identification.
Common ways for user identification are a small keypad for receiving a personal identification number (PIN), a biometric sensor, or a comparator for checking a PIN or other data received from computer/client workstation 160 (typically, input into client workstation 160 by a keyboard of the client workstation 160).
OTP interface 140 interfaces with authentication device interface 164 in order to exchange OTP-related data between OTP authentication device 110 and computer 160. In particular, whenever OTP generator 130 generates a session OTP, an OTP transmitter (not shown) “transmits” (i.e. displays and/or effects a data exchange to provide the session OTP data to the computer 160 via OTP interface 140) the session OTP from the OTP device 110.
Common implementations for OTP interface 140 are: a display 140A being used by a user in order to read the password and enter same manually into a keyboard that serves as authentication device interface 164 (then the preferred trigger 120 would be real-time clock 120B or counter 120C); a USB interface 140B (or other “contact” interface) that interfaces with a matching USB interface that serves as authentication device interface 164 to establish a two-way serial communication, or a IR/RF interface 140C (or other “wireless interface) that interfaces with a compatible infrared/radio frequency transceiver that serves as authentication device interface 164. In the cases of USB 140B and IR/RF interface 140C, all three approaches for trigger 120 are workable.
It will be noted that the case where OTP interface 140 applies display 140A, does not require any direct electronic communication link between OTP authentication device 110 and computer 160. In many examples, the user will enter both Session OTP data 140 read from the display 140B as well as user authentication data (i.e. for example, password and/or biometric data for the second of “two-factor” authentication) into the client workstation 160 where this data is combined to generate a two-factor authentication password (which is itself a type of OTP).
Server 170 allows server application 182 to provide a target service to client application 168 only upon the approval of OTP verifier 178. OTP verifier 178 includes processing and cryptographic means to check the password received from OTP authentication device 110 through computer 160, taking into account user key 132 and trigger 120. User key 132 is retrieved from user database 176, which includes the records of eligible users, including their username and key. The value of trigger 120 is retrieved by OTP verifier 178 from trigger synchronizer 174, which contains a challenge generator, a real time clock or a counter, corresponding to the method for trigger 120 selected from challenge 120A, real-time clock 120B and counter 120C, respectively.
FIG. 1B illustrates the same prior art system of FIG. 1A. In FIG. 1B, the deployment of the OTP authentication device 110, computer 160 (i.e. client workstation) and the server 170 are illustrated explicitly. More specifically, as illustrated in FIG. 1B, client workstation/computer 160 is connected to the wide-area network 20 through an Internet access link (for example, a broadband link, dialup link, SOHO link or any other ISP (Internet Service Provider) access link, or a cellphone internet access link for surfing with the cellular device) with a WAN gateway 22 provided by an ISP (an ISP access point). The server 170 sends a request for a session OTP via the wide-area network 20 (typically, using a packet-switched protocol) to the client workstation 160. Upon receiving this request by the client workstation 160, the OTP authentication device 110 transmits (either automatically or by a user entering via a keyboard of the client workstation) the session OTP to the client work station 160. This session OTP data is either directly forwarded to the server 170, or is combined with authentication data (i.e. password, pin, biometric) and then sent to the server 170 via the wide-area network (i.e. Internet) 20.
FIG. 2 describes the operation of system 100 of FIGS. 1A-1B, in accordance with some background art. In a step 201, a user of computer 160 launches client application 168. Client application 168 needs to communicate and interact with server application 182 in order to provide a desired target functionality for the user, such as access to data or making transactions. In a step 221 server application 182 responds to client application 168 with a request for user authentication by an OTP. This request is transferred to OTP authentication device 110, where OTP generator 130 requests from trigger unit 120, in a step 221, a trigger for generating the OTP. If the trigger is Challenge 120A the server 170 generates in trigger synchronizer 174 a random challenge string and provides it to OTP generator 130 through computer 160; if the trigger is any of real-time clock 120B or counter 120C, it is generated autonomously within OTP authentication device 110. In a step 231, OTP generator 130 processes trigger 120 and user key 132 to generate an OTP. In a step 241, the OTP generated in step 231 is sent from OTP device 110 to client workstation 160 which forwards data derived from the OTP to server 170. In a step 251, OTP verifier 178 calculates an expected OTP based on a the trigger retrieved from trigger synchronizer 174 and the user key retrieved from user database 176, and compares it with the OTP received from OTP authentication device 110 through computer 160. If the verification was positive, then a step 261 routes the process to step 271, where a client-server session commences to provide the desired target service through cooperation between client application 168 and server application 182; if the verification was negative, then step 261 routes the procedure toward a step 281, wherein server 170 rejects the service request received from computer 160, and the user is notified by computer 160.
The system described above, which uses a typical user authentication method of the background art, focuses on the authentication of the user (that uses computer 160) by a service provider (that operates server 170). This one-way authentication method has fairly protected service providers and users from user identity theft, until a new mode of fraud, coined “phishing”, was introduced and has even become a mainstream fraud method. In phishing, a user is addressed by an email message that pretends to come from his bank or a legitimate, reputable Internet commerce site. The message invites the user to update his details or conduct a commerce transaction. During this process, the user is required to authenticate himself, and the information that he provides is used by a criminal to steal the user's identity and provide other transaction on the user's behalf. The combination of username and password is extremely vulnerable to phishing, since the username and password surrendered by the users are reused for many more transactions by the criminal. The use of an OTP, dramatically reduces the effectiveness of phishing, but does not provide full protection against a phishing variation called “man in the middle”. In a man-in-the-middle attack, a message from a fake site starts what looks to the user as a legitimate banking or commerce transaction. While the transaction takes place, a criminal conducts a transaction of his own with the real site. The criminal passes-through the OTP-based authentication session and then conducts a transaction that transfers money or sends merchandise to himself or his partners.
There are a number of published documents related to techniques for increasing security in an environment where there is a risk of a man-in-the-middle attack. Potentially relevant patents and published patent applications include US20010045451, US20060041759, US6141752, WO2005098630, WO06018647, and WO06062838, all of which are incorporated by reference in their entirety.
The white paper “Enhancing One-Time Passwords for Protection Against Real-Time Phishing Attacks” from RSA Security, Inc. discloses technology where an OTP device (i.e. an electronic token) is used in conjunction with the client workstation. The OTP device is either in communication with the client workstation (for example, a “contact” OTP device communicating via a USB interface where trigger-derived data is provided via the USB interface) or is used by a human user who types a trigger-derive OTP-code (i.e. trigger-derived data) into a keyboard of the client workstation. The trigger-derived OTP-code (either automatically provided or copied from a screen of the OTP token) is combined, on the client workstation, with password/PIN data input into the client workstation to provide the “two-factor” password. More specifically, instead of inputting this password/PIN data into a browser and directly sending the combined data two-factor authentication data over the internet, a software “password protection module” (PPM) (typically separate from the browser) residing on the client workstation for receiving the user password/PIN is provided. On the client workstation, the PPM module combines the user password/PIN with the OTP data provided by the OTP device token. Before sending to the server from the client workstation, the combined data is encrypted/hashed by the PPM in accordance with an identity of the requesting server. This supposedly makes it difficult for a “man-in-the-middle” to access the hashed password and to learn the OTP data and/or the two-factor authentication data and/or the user authentication data.
Even though the PPM is typically a separate application from the attack-prone browser, one shortcoming of this prior art is that the Session OTP data is always provided (by the user or through a device interface) from the typically tamper-resistant OTP device to the potentially insecure client workstation, even if there is some risk that the server requesting the OTP authentication is no legitimate.
Due to the threat of phishing and man-in-the-middle attacks, there is an ongoing need for improved methods and apparatus for protecting OTP data from access by authorized parties.